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ABSTRACT 


This thesis proviies a critical analysis of -he Navy's 
Message Processing and Distribution System (MPDS) develop¬ 
ment. A historical approach is used in presenting the 
system's life cycle development beginning with the planning 
phase and ending with the integrated logistic support phase, 
several maintenance problems which occurred after the system 
was accepted for Fleet use were examined to determine if 
they resulted from errors in the acquisition process. The 
underlying intent of the thesis is to use the MPDS to exa¬ 
mine the critical decision points of the acquisition process 
and offer constructive recommendations for avoiding the 
problems which hindered the successful development of this 
system. 
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I, INTROPacnON 


The purpose of this thesis is to analyze the pertinent 
aspects of development and life cycle support of the Navy’s 
Automated Message Processing and Distribution System (HPDS). 
The historical section will discuss the imperative need to 
automate the Navy’s communication systems. It will then 
explain the Navy’s decision to begin developmental effort to 
automate many of the manual communications functions. 

The development of the MPDS will next be discussed with 
detailed emphasis placed on the following topics: 

1. Hardware Specifications 

2. Software Specifications 

3. Security Requirements 

4. Configuration Control 

5. Testing Procedures 

Next, a few unique problems with system maintenance, logis¬ 
tic support, and training will also be examined. 

Finally, cause/effect conclusions will be drawn and 
coupled with constructive recommendations for future major 
system development projects. 
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II. PROJECT HISTORY 


A. BASELINE II COMMUNICATIONS STUDY 

In October of 1966, the Commander of the First Fleet con¬ 
ducted a Communications Readiness Exercise to determine the 
Fleet's ability to handle large volumes of message traffic 
during simulated wartime conditions. This exercise was 
known as Baseline II, and it revealed the fleet was unable 
to handle large message volumes without encountering signi¬ 
ficant delays. These delays usually occurred in areas where 
humans were required to manually handle or process the mes¬ 
sages. Two of the areas where major delays frequently 
occurred were identified as the Naval Communication Stations 
(NAVCOMSTAS) and Radio Central on board the naval ships. 

The Naval Electronics Laboratory Center (NELC) in San 
Diego was directed to develop a system which would reduce 
the shipboard delays in message processing and distribution. 
The objective was to automate as many manual functions as 
possible. NELC installed the first experimental shipboard 
Message Processing Disnribution System (MPDS) aboard the OSS 
Oklahoma City (CG-5). This initial system was quite small 
and consisted of a single processor, magnetic disk storage 
device, and a high speed printer. Many updates and enhance¬ 
ments were added to this system as they became available, 
several remote printers were later installed at important 
locations throughout the ship, but no attempt was made no 
add remote interactive terminals (Ref. 1) Consequently, all 
outgoing message traffic had to be physically deposited at 
Radio Central for transmission from the ship. 

B. CVN-68 MESSAGE PROCESSING AND DISTRIBUTION SYSTEM 

At the same time that NELC was working on the CG-5 MPDS, 
it began work on the fully automated MPDS destined for ins¬ 
tallation on the USS Nimitz (CVN-68). This system was to be 
part of the ship’s original equipment, so it was extremely 
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important that the project's completion date correspond 
closely to the completion of construction of the Nimitz. Had 
HPDS not been ready and available on time, the Niraitz would 
have been forced to go to sea with an extremely degraded 
manual communications system. Consequently, proper manage¬ 
ment of the system's development by NELC was of immense 
importance if the Navy's readiness objectives were to be 
obtained. 

The Nimitz was originally scheduled to come out of con- 
struction in late 1973, but reactor delivery slippage caused 
several delays which resulted in a late commissioning in 
1975. Since the MPDS was behind schedule, the delivery date 
slippage for the reactors gave NELC and Planning Research 
Company (PRC) badly needed additional time to correct sev¬ 
eral software problems and install the completed system 
onboard the Nimitz in 1974 without causing any further 
delays. [Ref.2 ] 

NELC used the old aircraft carrier, DSS Bunker Hill, to 
test the operation of MPDS in a shipboard environment [Ref. 
3]. This procedure provided NELC with the opportunity to 
examine the effects of rhe shipboard electricity, excess 
humidity, and metallic influence upon the MPDS. 

C. MAINTENANCE PHASE 

In 1975 the Fleet Combat Direction System Support 
Activity, San Diego, (FCDSSA3D) , assumed system support 
responsibility for MPDS. During the following five years, 
eighteen major changes were approved and released which 
affected one or all of the following major systems: 

1. Operating System (OS) 

2. software Maintenance System (SMS) 

3. Equipment Maintenance Sub-system (EMSS) 

4. system Magnetic Tape Retrieval (SHR) 

[Ref. 4] 
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In 1976, the Navy awarded the MPDS software maintenance 
contract to Syncrotech Software Corporation in San Diego. 
This contract was "sole source" and went to Syncrorech 
because they employed a great number of PRC programmers who 
were involved in the initial development of MPDS [Ref. 5]. 


D. ADDiriOH&L INSTALLATIONS OF MPDS 

An identical copy of MPDS was late 
OSS Eisenhower (CVN-69), and a cop 
installed aboard the Vinson (CVN-70). 
response to the Chief of Naval Operat 
tronic Systems Command began a proj 
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III. aSALYSIS OF MPDS DEVELOPMENT PROCESS 


A. HARDBARE SPECIFICATIONS 
1. Available Hardware 

The initial specifications required that the project 
office "utilize equipment units or designs which are in 
being and readily available"[ Ref. 6]. A list of available 

equipment follows: 

Name Designation 

Central Processor CP-6423 

Magnetic Disk HD-281 

Magnetic Tape Unit (MTU) RD-294 


The decision to use available equipment offered the 
possible advantage of reducing development cost because it 
is much cheaper to purchase additional units than it is to 
develop the initial units. It also helps to improve the 
Navy's Supply System Purchasing Office's economies of scale 
since it serves to increase the overall purchase volume. 
This procedure also conforms to the Department of Defense 
Standardization Program which requires the services to pur¬ 
chase existing equipment. Using existing equipment involves 
less risk, so it helps prevent cost overruns and schedule 
slippages. It also lessens the logistic problems which are 
generally associated with unique equipment items. Items 
which are already in the Navy stock system often have 
maintenance contracts established with the vendors. Unfor¬ 
tunately, buying existing equipment did not solve MPDS's 
logistic problems because the manufacturers of many of these 
vendors stopped producing the equipment. Therefore 
repla cement has become increasingly difficult and equipment 
overhauls have become longer and more costly. 

2. hardware Development Items 

Many hardware items which were required for MPDS 
were not available in the naval stock sysrem and had to be 
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contracted out for development. Several of the major eguip- 
ments which had to be developed include: 


Wame DS§.i 2 Ilstion Contractor 

Line Printer TT 624 Data Products 

Magnetic Drum MU 570 RCA 

Display Keyboard AN/(JY\-9 Burroughs 


The Data Accumulation and Distribution Unit (DADU) 
was a very sophisticated and unigue piece of hardware which 
was developed to perform the system multiplexor funcrion for 
HPDS [Ref. 7]. The Blecrronic Switching Unit (ZSU) was 
another unit which had to be developed to allow all rhree 
processors access to the magnetic disk. The ESU has proven 
to be very reliable, but its failure would restrict rwo of 
the three processors from accessing the single disk. The 
OMI-43 is a device used to interface MPD3 with rhe fleet 
satellite broadcast. Common User Digital Information 
Exchange Subsystem (CUDIX). This device was developed after 
MPDS was accepted for fleet use, and it became apparent that 
MPDS required a backup system which would provide broadcast 
support during periods of major equipment failures. 

3. Equipment Specifications 

General requirements for all equipment developed for 
MPDS are referenced in the specification document [Ref. 8]. 
Military standards were referenced which set equipment 
requirements for temperature, shock, resistance, low level 
signaling and reliability [Ref. 9]. Functional specifica¬ 
tions for the hardware included processing rates required, 
code which it must be capable of processing, security 
requirements, and other general functional requirements. 

4. Areas Not Specified 

Difficulty meeting several of the original specifi¬ 
cations arose because the Navy was setting standards for new 
equipment which was destined for shipboard use and had to 
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perform functions which had not existed prior to the 
project. Consequently, numerous changes were proposed and 
made to the original specifications as the program effort 
progressed and the contractors experience improved in the 
new development. 

Many of the items which were developed for the pro¬ 
ject clearly lacked detailed specifications, so it was left 
to the personnel in the program office and the contractors 
to work out the details. The result was a description of 
what had been built rather than a specification of what was 
to be developed [Ref. 10]. Lack of specifications offered 
the advantage of allowing the program office and contractors 
the opportunity to make important changes to the system's 
design which frequently resulted in improved system 
performance. 

Dne change which improved system operation was the 
relocation of terminals in Radio Central. Originally, two 
terminals were to be used for control and placed at nhe con¬ 
trol console with another terminal placed in a maintenance 
area. The program office altered rhe arrangement by placing 
all three terminals at the cont.rol console, and this greatly 
improved the reliability of the control system because the 
AN/OYA-9 terminals have experienced a low mean time between 
failure (MTBF) and a high mean time to repair (MTTR) [Ref. 
11 ]. 

Lack of specifications also had many obvious disad¬ 
vantages. It was often difficult for the contractor and 
program office to know when a development was actually fin¬ 
ished because they had nothing to compare the finished 
product against [Ref. 12]. It proved to be a problem with 
the program sponsors because they would complain that "the 
Navy was not getting what it originally asked for" [Ref. 
13]. Allowing the project office the freedom to design the 
system where specifications did not exist tended to 
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encourage configuration confusion. It 
that a clear design pattern be outlined 
to prevent the developmental effort 
course. A detailed initial set of 
have resolved this conflict. 


is vitally important 
in the specification 
from wandering off 
specifications would 


B. SOFTWARE SPECIFICATIONS 

The original specifications required all software to be 
"modular in design such that addition, deletion, or change 
of function be made with a minimum of reprogramming" [P.ef. 
14], The requirement that the software be modular in design 
was fulfilled by the contractors. However major problems 
with adding modules and changing functions have occurred 
during the maintenance phase because of excessively high CPU 
core utilization. The specifications did not set utiliza¬ 
tion limitations upon the amount of core which the programs 
were permitted to consume. The requirement for the contrac¬ 
tor to meet performance specifications did serve to limit 
the amount of core which should be used and still meet per¬ 
formance objectives, but allowances were not made for future 
growth and program enhancements [Ref. 15]. 

1. Manual Security Measures 

The Informational Security System Design for MPDS 
was exrremely important because MPDS completely changed the 
structure of shipboard message handling and this created 
numerous new security concerns. Prior to MPDS, security was 
provided by the thick metal and heavy security doors around 
Radio Central. Distribution security was accomplished by 
restricting access to those individiuals who were designated 
in writing by their department heads. An up-to-date list of 
these personnel with their names, security clearances, and 
the highest level of message classifications that they were 
authorized to receive was continuously maintained a~ radio 
central,. This listing was checked any time an individual 
requested message distribution. 
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2. Automated Secarity Measures 


After MPDS, one method of providing additional pro¬ 
tection which was identified in the specifications was a 
coded device which would be used at the remote terminals to 
inform the control console of the classification level of 
the terminal [Ref. 16]. A security card reading device was 
never developed, but a manual code entry device was devel¬ 
oped whereby the user could type in his classification code 
and have messages and reports distributed to his terminal at 
the appropriate classification level. 

The project Office was afforded considerable lati¬ 
tude in developing a software system which was able to check 
the validity of the codes entered at the terminals. An 
operating system security module was developed which com¬ 
pared the code of the user to a Master Security List (MSL). 
Ihe MSL contained a listing of all the authorized users, 
their codes and the levels of security which they were 
cleared to access [Ref. 17]. The specifications also 
required special acknowledgement for receipt of top secret 
materials. Additionally, the completed HPDS provided a top 
secret disclosure sheet to assist the authorized recipient 
in maintaining tight control over the sensitive document. 

3. Dperating System Security Options 

[Jnfortunately, the projects software specifications 
did not address in detail several other new security con¬ 
cerns which were encountered in the new message handling 
system. Dne critical aspect of the software development 
which was not addressed specifically was the security pro¬ 
tection to be provided by the operating system. Since 
operating systems vary widely in the amount of protection 
which they provide for their data, it is prudent to specify 
the exact features that are desirable to be included in the 
system to be developed. 
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IBM marketed a protection mechanism in its operaxing 
systems called "locks" which served to prevent unauthorized 
read/writa accesses to secure blocks of memory. IBM also 
used the supervisoc/problem mode to distinguish between 
users and executive states. This differentiation helped 
prevent unauthorized alterations of instructions, storage 
protection locks, and the operating system [Ref. 18]. 

The Multics operating system which was developed by 
Honeywell Information Systems offered one of the most 
advanced security systems in production. It offered several 
sophisticated features which were not available on IBM Sys¬ 
tems. Dne important component was the internal password 
encryption which served to prevent illegal disclosure of the 
master password list. This protection was accomplished by 
encrypting the password which the user entered and comparing 
it against the internal password file. Therefore if a sub¬ 
versive agent were able to gain access to the computer and 
capture the internal password file, it would be of little 
value to him without the encryption cods. A second impor¬ 
tant aspect of the Multics Security system was the use of 
audit trails to keep a record of the users who accessed the 
classified data. [Ref. 19]. This procedure is extremely 
effective when the users review the audit trail on a regular 
basis and compare it against their access logs. 

4. System Vulnerability 

Security safeguards are particularly important in a 
multiprogramming/multiprocessing environment where the pro¬ 
cessors are required to handle multiple processes at the 
same time. These processes will usually have different 
security values and will be sharing the same system 
resources. A system or device which can guarantee complete 
isolation and protection of the secure process from unau¬ 
thorized access or disclosure has not been developed. Even 
the Multics system which was designed with security as one 


16 





















































of its primary objectives was penetrated by a special U.S. 
Air Force Tiger Team who was tasked to assess the security 
of the computers used by the Air Force. Security patches 
were used to correct the security weaknesses which were dis¬ 
covered by the team# but these patches didn't prevent the 
Tiger Team from making additional penetrations by exploiting 
other system weaknesses [Ref. 20]. 

Attempts to upgrade the existing level of MPDS security 
to include some of the features present in MOLTICS would be 
extremely costly and would not guarantee the security of the 
system. Since it is difficult to upgrade securiry, a pro¬ 
gram's sponsor must be very explicit in stating in rhe 
system specifications the type of security protection that 
is wanted. 


C. CONFI30RATION CONTROL 
1. FC5 Specification 

The control of system configuration proved to be one 
of the most difficult problems confronting the program off¬ 
ice. The lack of precise specifications was one of the 
major reasons for uncontrolled growth in the Facility Con¬ 
trol System (PCS). The Military Specification for rhe 
Message Processing and Distribution System for (CVAN-68) 
dated 30 Jan. 1967 required the following monitoring 
capabilities: 

3.2.1.11 A continuous or periodic indication of suspected 
channel trouble shall be provided to the Facility Control 
Console for those channels being processed automatically. 


The Specifications also provided the follow guidance on how 
PCS will interface with MPDS. 


3.2.1.10 The interface between the MPDS central processor 
and the PCS circuit sensing multiplexer# to provide for 
input of the communication circuit sensing signals to the 
MPDS central processor# will be a standard I/O channel of 
the central processor. 
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To comply wirh the above guidance, the project off¬ 
ice and contractor were forced to decide what type of 
sensing mechanism would be used to monitor or interrogate 
the channels and how often the sensing should take place, 
since both the contractor and the project office wanted the 
best system for the Navy, they frequently elected to develop 
a system which offered high performance as opposed to a less 
elaborate system which offered marginal performance at a 
smaller cost [3ef. 21]. ilany other decisions had to be made 
concerning "how to fulfill the specifications” and these 
eventually caused the FCS to grow in size, time, and cost. 

The completed FCS would have provided many benefits 
to the ship's communication personnel for it would have 
greatly reduced the amount of manual operator intervention 
required for channel and terminal connections. It also 
would have provided an increased quality control capability 
which has been desired for a long time by fleet communica¬ 
tion users. 

Despite the recognized advantages in operator cost 
reductions and improved system reliability, the development 
of FCS by NELC had to be cancelled by NAVSLSX because it was 
exceeding the original estimates for cost, resource utiliza¬ 
tion, and date for delivery [Ref. 22]. The amount of code 
and its corresponding core requirements had grown to such a 
degree that it was estimated that the completed FCS project 
would have required additional CP-642B central processing 
units if HPDS was to continue to meet the original perfor¬ 
mance specifications. 

It should also be noted that the implementation of 
FCS would not have significantly improved MPDS* message dis¬ 
tribution capabilities nor would it have increased the 
system's processing speed. The primary advavtages of FCS lie 
in it's improved quality monitoring and reduction in the 
number of operators required to manage the system. Since the 
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primary objective of MPD5 was to correct the shipboard 
communication deficiencies of slow message handling and poor 
message distribution which were revealed daring the Baseline 
II Communications Study, it is apparent that the FCS could 
only be viewed as desireable excess feature. 

2. Feasibility Study 

a. General Approach 

In June of 1970, Planning Research Company 
(PRC) , who was NELC's software contractor for MPDS, did an 
Intergration of Communication System Study which included a 
Quality Monitoring Trade-off Study. The goal of the study 
was to determine the feasibility of integrating an Automatic 
Quality Monitoring System (AQMS) and a Frequency Monitoring 
System (FMS) with MPDS. AQMS and FMS were originally 
designed to be two subsystems of FCS. Three areas of feasi¬ 
bility were examined; 

1. Technical 

2. Cost/Benefit 

3. Tine 

Positive conclusions were drawn about the feasibility of all 
three areas. PRC did recognize the interrelationships bet¬ 
ween cost and time and premised their positive time 
feasibility conclusions upon adequate steady funding. 

PRC compared the relative ease of operating the 
AQMS to the labor intensive Manual Quality Monitoring System 
and called the difference one of the benefits. The improved 
accuracy was also considered a benefit. The contractor did 
not try to quantify the value of these benefits. The amount 
of risk evaluated for the project was consistently rated as 
low. Appendix (A) provides a listing of the additional 
equipment and software required to develop the .AQMS and the 
associated degree of developmental risk [Ref- 23]. 
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b. Cost Computation 

PRC prsssnred the following AQM cost formula in 
their Technical Objective VII section 2.2.3: 

Cost in the present context is that expenditure associ¬ 
ated with the implementation of AQH expressed as a 

differential cost as follows: 

c = c - c 

AQM MQM 

where 

C = total integrated FC system cost 
AQM 

C = present FC system cosr 
aQM 

As shown above, the cost for AQMS was determined 
by subtracting the cost of the old manual system from the 
estimated cost of the automatic system. These costs were 
identified in Appendix (B). The exhibit provides a detailed 
listing of the additional hardware and software required to 
develop the automatic system and the estimated cost associ¬ 
ated with each item. 

c. Additional Cost Factors 

In addition to the three feasibility studies 
mentioned above, it would have been beneficial to include a 
section of study on organizational feasibility. This sec¬ 
tion would quantitatively evaluate the difficulties which 
the organization (ship) could expect when implementing rhe 
proposed system. 

The cost of implementation can become quite sev¬ 
ere if the sailors view the new system as a thraaz to their 
security. These feelings often develop because the sailor 
was not trained in the operation of the new system, and he 
feels his position of knowledge and authority is in jeo¬ 
pardy. The sailors may respond to the perceived threat with 
either passive or active resistance [Ref.24]. Any resis¬ 
tance to a new system will invariably cause both delays in 
implementation and increases in the final project cost. 
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Although it is often difficult to accurately 
anticipate the exact amount of resistance which will be 
encountered and the resulting cost, an attempt must be made 
if the project costs estimated are to reasonably resemble 
the actual cost. MPDS experienced its share of operator and 
maintenance personnel passive resistance, and it is reason¬ 
able to conclude that the FC3 would also have been received 
by the ship’s crew with mixed feelings. 

A comprehensive cost/benefit analysis would also 
have estimated the cost of training the fleet sailors to 
operate and maintain the proposed system. Appendix (B) and 
Appendix (C) do not address these costs. These areas had 
the potential to become very cosrly for several reasons. 
The fact that the FCS project was unigue to the large 
(CVN-68) class carriers would have made some additional 
training activities necessary. New instructors would have 
to be trained, class training plans and lessons would have 
to be prepared, and training materials would have to be pur¬ 
chased. All of these efforts and expanses would have been 
for very small classes and would have to be completed before 
qualified personnel could be sent: to the ship to operate the 
new system. 

PRC's method of computing the cost by subzract- 
ing the cost of the MQK from the cost of the AQMS may not 
have revealed the full cost difference because AQMS was 
designed to utilize existing MPDS equipment. This utiliza¬ 
tion imposes a cost upon the entire system in the form of 
either reduced performance or smaller reserve capacity avai¬ 
lable for future growth. 

In order for the Navy to have made a completely 
knowledgeable decision about the feasibility of the proposed 
project, it would have been necessary to identify all of the 
costs, (including cost of using existing systems), and to 
assign quantifiable values to the benefits. 
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3. Report Senarator 

Another area of the MPDS project development which 
experienced excessive growth was that of reports which were 
generated or could be retrieved at rhe remote locations. 
The military specifications addressed this issue in several 
locations. 


3.2. 1.9 Storage and retrieval capabilities for long-term 
files shall be provided. 

3.2.2.2.5.1 It shall be possible to retrieve all or 
selected portions of the log information either on 
demand, in which the operator inputs a reguest to the 
system by kevboard, or periodically, in which case the 
log information is output without operator information. 
Both hard-copy and soft-copy retrievals shall be possi¬ 
ble. 


The following portion of the specifications provides 
a general framework for the types of information which the 
system would be required to accumulate and disseminate: 

3.2.2.2.5 Automated message accounting shall include; 

(a) Attachment of unique system message numbers for 
accounting and retrieval purposes. 

(b Journalling of messages for accounting purposes. 

(c) Extracting of statistical data from message 
traffic. 

(d) Special accounting for top secret message deliv¬ 
ery . 

To determine the type of reports required and the 
elements of data which have to be accumulated and stored, 
the project office consulted with the users. That which 
resulted was a system which was originally developed to pro¬ 
duce 47 different reports [Ref. 25]. This placed a heavy 
burden upon the entire system and greatly increased the 
amount of secondary storage required by the system. These 
reports were printed at periodic intervals but could also be 
retrieved upon demand by the users at their terminals, pro¬ 
vided the requested information was within the security 
range of the user's terminal. Initially, every user could 
retrieve any report contained within the system. Since 
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retrieval of long routine reports during peak message load¬ 
ing periods severely degraded overall system performance, 
and a genuine need to know could not be substantiated from a 
terminal retrieval request, future changes to ;iPDS res¬ 
tricted report production to scheduled runs unless special 
off-line requests were submitted and approved [Ref. 26]. 

Recent software changes which have been released to 
the fleet have corrected many of the problems with the ini¬ 
tial report package. These changes have limited both the 
content and distribution of several periodic reports.Surveys 
of the fleet user groups have resulted in adding important 
tracking programs which generate reports on various aspects 
of system performance. 

One, recently added, provides critical information 
to the Communication Officer about system message volume 
during peak loading periods. This data was either missing 
in the original 47 reports or it was obscurely buried where 
it could not be used or readily accessed by personnel who 
needed the information [Ref. 27]. It became evident that 
the initial querying of the users produced an inaccurate 
composite of their requirements. The reports which MPDS 
produced resembled what the user thought that they wanted 
rather than what they truly needed. 

This lack of user understanding of his actual 
requirements became apparent in the development of the UI-9 
remote receiver/transmitter user terminal. Seventeen func¬ 
tional buttons were designed into the terminals to satisfy 
the users' requirements. Usage patterns have shown that the 
operators seldom use more than six of the functions. Five 
of the other functions were used by the maintenance person¬ 
nel. The net result was six user specified functional 
capabilities designed into the system terminals which were 
not productively utilized [Ref. 28]. 
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D. TESTING 

1. Broadcast Screening Test Objectives 

Special testing of the MPDS broadcast screening 
capability was conducted by Naval Electronic System Command 
Southwest Division (NAVELECSYSCOMSOHESTDIV) at the MPDS test 
bed at NELC on May 14, 15, 16 and 18, of 1973. The total 

test time was 28 hours. Excerpts of real world live traffic 
were taken from four different geographic broadcast areas in 
the Atlantic, Eastern Pacific, Western Pacific, and the Med¬ 
iterranean. The primary objective was to test the system’s 
ability to correctly compare the addresses of the various 
broadcast messages against the addresses contained in the 
MPDS guard list (GML). The GML contained approximately 150 
addresses [Ref. 29], A second test objective was to deter¬ 
mine how accurately the system could automatically read and 
distribute the incoming message to the appropriate remote 
terminal. 

2. System Inprovement Tests 

Several System Improvement Tests (SIT) were also 
conducted by NAVELECSYSCOHSOWESTDIV. These SIX'S were given 
to evaluate the effectiveness of modifications made to the 
hardware/software subsystem. Numerous modifications were 
made to the system for the purpose of resolving Problem Work 
Sheets [Ref. 30]. 

3. Users Involvement in Testing 

The Broadcast Screening Test and SIT both used Nim- 
itz (CVN-68) crew members to operate the system. Utilizing 
the future operators of the system for test operations pro¬ 
vides many advantages to the project team. First it 
provides them with an excellent opportunity to train the 
future users in the proper operation of the equipment. It is 
also an excellant opportunity to instill in them valuable 
confidence in the system. This confidence can be a very 
important advantage to the project team during the 
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implementation phase [3ef. 31], The spirit of cooperation 
and friendship which often developes between the developer 
and fleet operators during the testing phase can go a long 
way toward over coming the skepticism and resistance which 
often plagues projects in later phases. Finally/ the project 
team can receive important feedback from the operators con¬ 
cerning operational difficulties and constructive 
suggestions for system improvements, 

4. Restrictive Testing Procedures 

Mthough the primary objective of testing the broad¬ 
cast screening capability of MPDS was fulfilled, the results 
of the test were obtained under very restricted conditions. 
Had they been obtained under simulated or actual operational 
conditions, then the project team would have known how the 
system would function when it encountered the technical and 
human stresses associated with fleet operations [Ref, 32]. 
Massage and report retrievals are two operations which sig¬ 
nificantly increase the stress upon the system. Neither of 
these functions were permitted during the Broadcast Screen¬ 
ing Test. Experience has shown that the combined effect of 
these two processes can seriously reduce the overall effec¬ 
tiveness of system performance. 


25 











































IV. INTEGRATED LOGISTIC SUPPORT 


A. SOPPDRT ACTIVITIES 

1 . FCD5 5A5D 

In 1975 FCDSSASD was originally tasked to provide 
life cycle maintenance for the Message Processing and Dis¬ 
tribution System. To facilitate this support, a special 
suite of equipment, (identical to the MPDS equipment onboard 
USS Nimitz), was installed at FCDSSASD [Ref. 33]. 

2. NTSIC 

In 1979 the Naval Telecommunications Systems Inte¬ 
gration Center (NTSIC) assumed life cycle maintenance 
responsibilities for MPDS [Ref. 3h]. NTSIC has a duplicate 
model of the MPDS hardware and software which is presently 
onboard the USS Nimitz and US5 Eisenhower. This model 
serves as a testing facility for all new software modifica¬ 
tion and hardware changes before they are delivered to the 
fleet for installation. 

NTSIC also serves as coordinator for all software 
change proposals (SCP) [Ref. 35]. A sample list of SCP can¬ 
didates for MPDS software change release #10 is shown in 
Appendix (D). This list was developed by sending question¬ 
naires to the fleet users and compiling the results. The 
candidates for change ware then discussed with the senior 
communications personnel from the carriers prior to the 
meeting of the Communications Change Control Board (CC3). 
Only change items which received unanimous user support and 
agreement were forwarded to the formal (CC3). Final Comman¬ 
der Naval Telecommunications (CNTC) approval for software 
changes is based upon the outcome of the board. NTSIC is 
intimately involved with every step of this process [Ref. 
36 ]. 

3. Svncrotec Software Corporation 

The MPDS software maintenance contract was awarded 
to Syncrotec from San Diego. The fact that many of the 
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original HPDS software development programmers l<ft Planning 
Research Corporation (PRC ), (the original software contrac¬ 
tor) , and went to work for Syncrotec weighed he<vily in the 
decision to select them as the software maintenai ;e contrac¬ 
tor. Since MPDS had unique software to perform difficult 
applications, it was important to choose a software mainte¬ 
nance corporation which had experience with the system. 

B. TRAINING 

1. Initial Training 

Commander Franson, who is the Deputy Director of 
NAVTELSYSIC, described the first training of the Nimitz's 
precommissioning crew as being very successful. This was 
due in part to the high priority that the project team 
placed upon utilizing every training opportunity. The Exe¬ 
cution Plan for Operational Capability Evaluation 
(OPCAPEVAL) stated the following training objective: 

*' Every effort will be mad^ to make the HPDS available 
to the Nimitz crew for training during contingency per¬ 
iod. " 

This training was in addition to practical experience which 
the crew . members obtained while operating and maintaining 
the equipment during the scheduled test periods. Appendix 
(E) provides a schedule of events which occurred during the 
OPCAPEVAL and the long periods designated for system train- 
in g [ Ref. 37 ], 

2. Operational Training Problems 

After the system had been implemented and the USS 
Nimitz became operational, training deficiencies began to 
surface. These deficiencies became especially evident when 
the USS Nimitz made her overseas deployments. In a trip 
report from two Synchrotec software technicians, the follow¬ 
ing comments were made concerning training [Ref. 38]; 

"The lasting impression that remains with us however, is 
that the weakest link in the operation and performance 
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of M?D3 is now unquestionably the operators themselves. 
Knowledge of basic communications procedures and prac¬ 
tices (let alone, knowledge of HPDS) was sadly lacking 
among many of the second and third class petty officers 
aboard ship, and until the sailors are familiar with how 
to communicate in the Navy environment, we can hardly 
expect them to become proficient at operating HPDS." 

This concern about the level of shipboard personnel training 
was also shared by the officers onboard the USS Nimitz. In 
a message to the Commander of the Sixth Fleet (COMSIXTHFLT), 
the Commander of Task Force Sixty (CTF SIX ZERO) made the 
following comments (Ref. 39]: 

"There is no software expertise onboard Nimitz capable 
of providing the level of support that recent operations 
have documented as required to maintain HPDS in even a 
marginally operational status. . . . The onboard soft¬ 
ware techs should be relieved by a technician qualified 
in system restoral and installation of system fixes. 

It is clear from the above statements that the shipboard 
technicians lacked understanding about how HPDS operated and 
how to maintain the system. This leads to the obvious ques¬ 
tion of how did the USS Nimitz's training profile drop from 
its initial high state to one which can barely maintain 
operational capability. 

3. Scarcity of Instructors 

The commander of Naval Education and Training 
(CNET), who is in charge of training conducted in the Navy, 
had extreme difficulty finding qualified instructors to 
teach HPOS operator and maintenance classes. There are sev¬ 
eral reasons why this problem developed. 

a. The Commissioning of the Eisenhower 

When the Eisenhower got commissioned, it 
required a full compliment of qualified operators and 
maintenance technicians to take her to sea. Her precommis¬ 
sioning crew did not have the advantage of being able to 
participate in the system development of HPDS as the Nimitz 
precommissioning had dona. Consequently, they were not as 
well trained, and qualified personnel had to be acquired 
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from either the Nimitz or ashore. Since the training 
command had second priority to fleet units for personnel 
manning# CNET could not obtain or retain rhe instructors 
that- it needed to conduct MPDS classes [Ref. 40]. 

b. Sea/Shore Rotation Problems 

The shortage of trained personnel combined with 
the expanding need for sailors who possessed MPDS operation 
and maintenance experience caused a serious exrension of 
the normal sea/shore rotation interval. A sailor could 
routinely expect to receive orders from the USS Nimitz to 
the OSS Sisenhower rather than the typical rotation ashore 
which most sailors have grown to expect. The net effect of 
this extension at sea has been a severe reduction in the 
number of qualified personnel staying in the Navy. 

c. Civilian Opportunities 

The third reason for CNET being short of 
instructors is the intense demand for individuals with high 
technical expertise in the civilian market. These civilian 
firms usually offer very high starting salaries to qualified 
personnel. Since MPDS technicians were generally some of 
our most highly trained sailors# their marketability was 
exceptionally high. With the rapid exodus of highly trained 
technicians and barely enough personnel to man the fleet 
units, it was not surprising that CHET was unable to provide 
the necessary number of instructors to conduct the courses. 

4. NTSIC Solution 

Although training is generally conducted by CNET# 
the lack of available instructors made it impossible for 
CHET to adequately train the :1PD3 operators and maintenance 
personnel. NTSIC attacked the training problem in two 
areas. First, they sent NTSIC MPDS specialists onboard the 
aircraft carriers during their deployments to train them in 
operating and maintaining the system under heavy stress. 
Secondly# they offered an 18 week maintenance course and a S 
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week operators course at regular intervals to pr 
sailors, who were ordered to the iJSS Nimitz or the 
Eisenhower, for their jobs. These courses have proven 
very beneficial in improving the ships* capability to 
ate and maintain the MPDS with their own personnel. 

5. Alternative Design to :iPDS 

a. Description of NAVMAC5 

Many of rhe problems encounrerad in trainin 
crews of the QSS Nimitz and USS Eisenhower in zhe p 
operation and mainrenance of MPDS have nor been experi 
by fleet units using the Naval Modular Automated Commu 
tions System (NAVMACS). The NAVMACS program provid 
family of Automated Communications Systems sized to nee 
needs of all sizes of ships. The classes of NAVMACS 
from the most basic NAVMACS VI and increases in sophis 
tion and capability through the NAVMACS V2, V3, and V5. 
prime advantage of this system is that the more complex 
terns retain and build upon the components of the 
system. Appendix (F) provides an example of how the 
advanced systems utilize the standard hardware of the s 
system [Ref. 41]. 

b. Training Advantages of Modular Design 

The above approach to system development o 
several training advantages over the MPDS. The rra 
task is much easier because sailors who are enroute 
ship which has the NAVMACS VI basic system installed 
be trained with students who are destined to serve 
NAVMACS V3 ship. This is possible because both sy 
share the same basic modules. The problems of small 
classes and lack of qualified instructors which tro 
MPDS are not a problem with NAVMACS [Eef. 42]. CNE 

been able to successfully fill its instructor billets, 
the increased size of the classes has provided CNET 
substantial economies of scale. 
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0 . MPDS Replacement System 

The NAVMACS V5 will offer the same basic message 
processing and distribution services as MPDS. It is cur¬ 
rently scheduled to be installed on all of rhe future CVN’s 
after the Vinson. It is also scheduled to replace the MPDS 
units on the Nimitz, Eisenhower, and Vinson, as they undergo 
their regular overhauls. CNET will assume training respon¬ 
sibilities for this system [Ref. 43]. 

C. MAINTENANCE 

1. System Reliability Problem 

System reliability is one of the greatest concerns 
for users of online computer systems since the primary rea¬ 
son for installing such systems is to satisfy the need for 
immediate information. This need for reliability becomes 
even more important when the online system is tasked with 
carrying tactical and strategic intelligence messages which 
may effect the wartime readiness posture of the host ship 
and any ships subordinate to it. 

The problem of MPDS reliability was addressed in a 
letter from the commander of Carrier Group Two (who was 
embarked onboard the USS Nimitz) to the Commander Naval Air 
Force, (J.S. Atlantic Fleet. 

Erratic reliability was the primary MPDS deficiency. 
The fact that reliaoility invariably declined as traffic 
volume rose made unreliaoility a particularly sensitive 
problem. . . . Reliability of 99.5'] is considered a rea¬ 
sonable standard of satisfactory performance [Ref. 45]. 

2. Equipment Problems 

Many of the hardware items which were developed 
especially for MPDS became maintenance problems. Low mean 
time between failures (MTBF) and/or lack of replacement 
parts were the two primary reasons for excessive system down 
time. Following will be a discussion of hardware problems 
related specifically to the Data Acquisition and Distribu¬ 
tion Unit (DADU) and to the MU 570 Drum; 
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a. The DADU 


The Data AcguisitiDn and Distcibution Unit 
(DADU) TD 1066, which functions as an inpur/output control 
interface unit, is unique in design and is considered essen¬ 
tial for normal operations. This unit has been a continuous 
maintenance concern since the system was first installed on 
the Nimitz in 1974. The Supervisor of Shipbuilding at New¬ 
port News, Virginia, wrote the following comments to Admiral 
Kidd about the need for logic and control printed circuit 
cards for the DADU. 

No replacement cards are available to immediately 
satisfy Nimitz's demands when one of these . . . cards 
fail, which is often. It has become apparent that lit¬ 
tle attention has been given to ensuring adequate 
provisioning for unique MPDS hardware [Ref. 45]. 

DADU failures have frequently interrupted normal shipboard 
message communication since its initial insrallation. Its 
breakdowns have necessitated Synchrotech maintenance spe¬ 
cialists to take long ship rides with the USS Nimitz to fix 
the DADU and restore the system t.o normal operational 
ca pability. 


Operational units were 
to suffer degraded mission readir.es 
ble equipment. The Fleet Combat 
Activity which originally provided 
MPDS also experienced operational 
failures. This was due primarily 
logistic support. The failures r 
reduction in the unit's ability 
requirements [Ref. 46]. 

In March of 1978, Capt. 
a hardware system engineer for Ma 
Denver, Colorado, did an analysi 
weeks of active duty with the Nava 
mand. He made the following remark 
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A. E. Huff USNR, who was 
rtin Marietta Company in 
s of MPDS during his two 
1 Electronic Systems Com- 
s about the DADU; 
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since only four of these DADU units presently exist, the 
ESO procures replacement boards on an "as call basis". 
This creates longer than usual replacement time and 
costs around $1000 per card [Ref. 47], 

Sapt. Huff stated that an item which could serve as a 
replacement for the DADU is a unit called MICS. It is cur¬ 
rently being used by the Air Force's Strategic Air Command 
with apparent success. The modern circuit technology used 
in MICS is estimated to reduce maintenance cost by as much 
as 90] and greatly increase reliability, 
b. MO 570 Drum 

MPDS was designed with two drums to provide 
added capacity and redundancy. The initial specifications 
called for a single IBM disk unit, but the contractor. Plan¬ 
ning Research Corporation (PRC), wisely convinced the 
Government Project Office of the need for the increased 
speed which was available in the MO 570 magnetic drums [Ref. 
43]. The drums have also been characterized by low MTBF and 
frequent logistic problem. However, the failure of one drum 
does not force the entire system to shut down, which is what 
occurs when the DADD fails. This is because the second drum 
is capable of supporting the system in a degraded mode, 
c. General Hardware Characteristics 

MPDS was designed with a tremendous amount of 
hardware redundancy. The system is programmed to gracefully 
die without interrupting normal message processing until the 
last spare unit collapses. This feature of MPDS is 
extremely valuable when the system is experiencing heavy 
loading while fulfilling operational commitments. During 
these periods, it would be very difficult to shut down the 
system for troubleshooting, so the designers mads this 
procedure unnecessary by providing sufficient equipment 
spares to allow the system to continue to operate [Ref. 49]. 

3. Omissions to the Functional Description 

Several maintenance problems surfaced when the fleet 
users discovered that the new system did not do everything 
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that they needed. Two areas which were of particular 
concern to the users were message storage limitations and 
NATO message handling. 

a. Message Storage Limitations 

The Commander of Carrier Group Two, who was 
embarked onboard the USS Niraitz, was deeply concerned about 
the system's limited online message retrieval capability. 
He wrote the following comments in a letter to his Command¬ 
ing Offioer: 

The existing MPDS capacity did not provide sufficient 
online message storage to permit more exrensrve user 
recall of recent messages . . . hence duplicate paper 
files were maintained to provide conies of messages that 
had been removed from online storage. Ten aavs of 
online message recall capability is considered a reason¬ 
able target [Ref. 50]. 

Although the system was obviously not providing adequate 
message retrieval services, it was performing up to the 
standards outlined in the Functional Description. The fol¬ 
lowing is the message storage requirement contained in the 
Functional Description: 

3.2.1.10 System messages and associated . . . entries 
shall be stored for approximately three days on online 
mass storage to support duplicate search. messaaa 
retrieval, report generation and other functions [Ret. 

51 ]. 

b. NATO Message Processing 

The capability to process North Atlantic Treaty 
Organization (NATO) message traffic was not included as part 
of the automated MPDS. Consequently, the USS Nimitz was 
required to process NATO traffic manually during a large 
part of her deployment to Furope [Ref. 52]. Several tempo¬ 
rary patches were mads to the system to allow for partial 
automated handling of NATO messages. The commander of Task 
Force Sixty wrote the following to the Commander of rhe 
Sixth Fleet: 
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without the partial 
achieved by patches. 
NATO traffic) would 
53]. 


automated NATO processing capability 
the tasic (of orocessing ail of the 
have been close to impossible [Ref. 


The Functional Description for M?DS made no 
requirements for NATO automatic message processing capabili¬ 
ties. A permanent software change to allow automatic 

processing of NATO massages was installed onboard the USS 
Nimit 2 after the completion of the deployment, 
c. Message Traffic Estimates 

Naval telecommunications message traffic has 
been increasing each year as the quality and speed of ser¬ 
vice has continued to improve. The Military Specifications 
for MPD3 were written in 1967 when the average traffic 
volumes for aircraft carriers were much lower than what 
would be found in the fleet today. The following MPDS 
requirements are taken from the original Military 
Specification; 


3.1.14 Data rates and capacity.—The system when oper¬ 
ating ’’on-line" shall . . i be possible to handle up to 
2500 average messages per day and to retrievably store 
up to 7500 average messages. 

3.1.13 Average traffic units.--System capacity and pro¬ 
cessing rate requirements herein shall be based oh an 
average message length of 200 words [Ref. 54], 


The average length of messages has increased to above 200 
words because fleet units are now sending more administra¬ 
tive traffic over the fleet broadcast which used to be 
delivered by mail. 

MPDS has been required to process average mes¬ 
sage volumes in excess of 3500 messages per day when the USS 
Nimitz had the Task Force Commander embarked during major 
fleet exercises in the Mediterranean Sea [Ref. 55]. 

4. The Effects of Operations Doon Maintenance 

The urgent necessity of intense fleet operations has 
frequently been the cause for delays in both corrective and 
scheduled maintenance. During the 1976 deployment of the 
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USS Nimitz, several hardware and software problems developed 
which coaid not be handled by the ship's maintenance crew. 
Synchrotech sent a software team aboard the carrier during 
part of the deployment to correct problems and make recom¬ 
mendations for system improvements. Following are a few 
comments made by the software specialist concerning their 
shipboard experience: 

It is nearly impossible to debug a software system in an 
operational environment, expecially with traffic volumes 
which are typically associated with a flag command. The 
system cannot be surrendered to the exclusive use of 
programmers to test and debug ... an outage of even 30 
minutes creates traffic backlogs untenable to the sraff 
and ship users [Ref. 56]. 

It is evident from the above statement that a sysrem with 
low MTBF would function more successfully in an intense 
operational environment. Another way of solving the mainte¬ 
nance problem is to design a system which offers a short 
mean time to repair (MTTR). Kany systems are available 
today which are modularly constructed to allow average tech¬ 
nicians to pull the defective module and insert a 
replacement module in a very short time frame. 

5. Improved Reliability 

MPDS has now been in the fleet for six years. Dur¬ 
ing this time the operators and maintenance personnel have 
acquired a wealth of valuable knowledge about the system. 
This increased knowledge has enabled the fleet users to 
maintain the system in a higher stats of readiness. ilany of 
the original maintenance problems were due to the fact that 
it is difficult to maintain an unfamiliar system regardless 
of the level of technical expertise of your personnel [Ref. 
57]. 

Synchrotech software specialists were called aboard 
the USS Himitz to solve several technical problems which 
appeared to be beyond the technical ability of the ship's 
maintenance crew. The software specialist said the 
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following about the magnetic drum failures in the trip 
report which they submitted: 

Magnetic drums—The message file clerks, who use a work 
area and table which is mounted directly in front of the 
drums, were stacking burn bags (bags full of old mes¬ 
sages which are scheduled to be burned) on the floor 
directly in front of the drum. This restricted the 
badly needed air circulation required by the MU-570 drum 
to maintain a reasonable ambient air temperature, and 
the drum began experiencing intermittent errors. Remo¬ 
val of the bags resolved the problem [P.ef. 58]. 

This is an example of how the operators learned valuable 
information about the heat sensitivity of the drums and the 
air circulation patterns in the computer room. This infor¬ 
mation should be available for future operators of the 
system and consequently further heat problems with the drums 
should be avoided. The net summation of these learning 
experiences is quite often a more reliable system. 

Another factor contributing to improved performance 
was the installation of 18 software releases by FCDSSASD and 
NTSIC [Ref. 59]. These software releases have provided 
incremental improvements to the operating system, mainte¬ 
nance subsystems, and the retrieval subsystem. They have 
added the capability to process NATO messages, accumulate 
and process useful data for periodic reports, and generally 
improve overall system performance. 
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7 COHCLasiOH AHD RECOaWENDATIONS 


A, OVEa7IEH 

The MPDS project history has provided a classic example 
of how failure can occur in the military computer acquisi¬ 
tion process. This failure was the result of the Mavy not 
giving sufficient attention to four major elements of the 
acquisition process. 

The first and primary problem was the Navy's failure to 
do detailed planning at the beginning of the project prior 
to initial developmental work. Inadequate time spent upon 
planning resulted in the project not having a well mapped 
course to follow. Cost over runs and problems with mainte¬ 
nance, training, and logistics could also be attributed to 
poor planning. Eighteen change releases by the Navy's sys¬ 
tem support activities were required to correct many of the 
problems which had their origins in the system planning 
phase. 

Failure to freeze the design early in the project was 
another significant problem with the developmental process. 
The Facility Control System's design was permitted to change 
and grow until the system had to be terminated because it 
was going to make the entire aPDS project late and drive the 
total cost of the project beyond acceptable limits. Project 
scheduling problems developed because no one knew when the 
FCS would be finished since it was not known what the fin¬ 
ished product was supposed to look like. 

Ambiguous and/or incomplete military specifications also 
contributed to the project office's problems. The project 
office had to make design decisions on an adhoc basis with¬ 
out the benefit of the explicit directions usually contained 
in the specifications. The composite of these decisions was 
a system which provided too many reports of minimal value, 
terminal functions which were not used, and which could not 
operate in a NATO environment. 


38 
















Finally a comprehensive cost./benefit analysis was never 
performed to determine the true feasibility of the proposed 
systems. The high risk associated with the FCS was never 
fully recognized in the feasibility study. Alternative sys¬ 
tems were not considered in the feasibility study. As a 
result of the above, the service wasted a lot of money while 
pursuing the development of a system which never material¬ 
ized. The lack of alternative systems in the feasibility 
study deprived the Navy of the option to select a more 
appropriate design. Appendix (G) lists several of the alter¬ 
native design options which were available for 
consideration. 

B. RECOHHENDATIONS 

More time needed to be spent in the planning phase to 
prepare a comprehensive Configuration Management Plan, 
Training Plan, Security Plan, and Integrated Logistic Sup¬ 
port Plan. These documents would have provided guick 
reference for the project team to use when confronted with 
major decisions. The plans would have contained procedures 
for establishing a change control board and would have out¬ 
lined the major project objectives for training, security, 
and logistics. Such detailed guidance was badly needed by 
the MPDS project team and would have prevented many of the 
problems which resulted from the adhoc decisions. [I?ef. 63] 

A Program Plan which provided for periodic reviews would 
also have been helpful to the project team. One of the 
functions of the review team would be to consider freezing 
the system/subsystem's design. Early freezing of the FCS 
design could have prevented that system's development from 
falling behind schedule. 

Future computer system acquisitions should place heavy 
emphasis on preparing thorough and clear specifications. 
This could be accomplished by establishing a specification 
review team consisting of both system sponsors and technical 
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users who will initially verify the original specification 
and who would later approve/disapprove specification 
changes. This would have prevented many of the problems 
which occurred in the MPDS project where the users and spon¬ 
sors received a product which was different nhan they had 
requested. 

Concise specifications have the advantage of focusing 
heavily upon the end product. Such focus tends to prevent 
the technicians from becoming overly intrigued with the 
technical sophistication of their system and forces rhem to 
concentrate on developing an end product which matches the 
specification. This procedure would limit or reduce the 
problem of acquiring extremely sophisticated hardware and 
software as the Navy did with MPDS because the developers 
would not be given a blank specification sheet where they 
could fill in the details. 

To ensure compliance with the above objectives, it is 
recommended that Project Sponsors include them in the Letter 
of Instruction (LOI), which signals the beginning of the 
acquisition process. By placing these requirements at the 
on-set of the project, they will receive the attention rhat 
they require at the appropriate time. 
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APPENDIX A 


AQH ADDITION DEVELOPaENT RISK ESTIMATES 


Development Risk Function 

p— 

Risk Estimate 

QOALITI MONITORING SYSTEM 

- 

Signal Sensor and Samplers 

low 

Scanner-Multiplexer Converter (A/O) 

low 

Frequency Monitoring System 

low 

. - ] 

Quality Monitoring Software 

1 

low* 

Frequency Monitoring Software 

low* 


J 


* Predicated upon the availability 
of adequate support software 
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APPENDIX B 


AQM DIFFERENTIAL COST ESTIMATES 


r —\ 

1 COST ELEMENTS 

1- -, 

COST ($K) 


. J 

QOALITY MONITIORING SYSTEM 


Signal Sensors and Samplers 

5 

Signal Conditioners 

7 

. . . . 

Scanner Multiplexer 

. - . - . - . 

14 

A/0 Converter 

1 

. . . 

Frequency Monitoring System 

_ 

10 

... . 

Installation 

17 

Quality Monitoring System Software 

. . . . . - _ 

r 

10 

Frequency Monitoring System Software 

15 

_j 


Total=$791c 
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APPENDIX D 


OPEN SCP*S MPDS C7N-68 CLASS 




CANIDATE FOR RELEASE 10.0 





1 



Cast' 


Pr e 




CNTCt 

SCP REL 

1 ^ 

1 • 

1 O 

1 

CCE 

CVN-68 CVN-69 CVN-70 

CC3 

NTSIC 

CCB 

APPRI 

0 00 2 

# 








0003 

0004 

# 

X $ 

X 

H $ 

H 

S 

H $ 


0005 

0006 

0 00 7 



c 

H 

H 


H 


0008 


X $ 

X 

H S 

H 

$ 

H $ 


0009 



C X 

c 

C 


C 


0010 


X 

X 

X 

X 


X 


0011 

. 



X 

X 

X 


X 


0012 


X $ 

X 

H $ 

H 

$ 

H $ 


0014 

0016 

# 

X 

c 

c 

C 


C 


0017 



? $ 


X 






0018 


X 

X X 

X 

A 


X 


0019 



X 

c 

C 


C 


0020 

0023 



c 

c 

c 


c 


. 









0025 

0026 

# 

X 

c 

c 

C 


C 


0027 



X 

c 

H 


H 


0030 



c 

c 

H 


H 

-1 


# - Approved by last CC3 for Rel 9.0 
? - Request CNTC Approval for Rel 9.0 
X - Recommended or Requested for Rel 10.0 
H - Recommended for Hold Open 
C - Recommended for Cancel 
R - Review 
$ - Require ECP 
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APPENDIX E 


OPCAPEVAL TEST SCHEDDLE OF EVENTS 


- 1 

r — — . r -- 

DATE 

TEST/EVEHT 

■ 


TEST PERIOD A 


20-22 Aag 1973 

Interconnection Verification Test 

23-24 Aag 

On-Line Confidence Test 


Off-Line Confidence Test 

2 5 Aug 

Security Composite Test 


P-Series on System 10 

26-28 Aag 

OPCAP Phase III on System 10 

29-30 Aag 

System Debug System 11 Preventive 


Maintenance Test System 11 

3 1 Aug 

security Composite Test p-Series 


on System 11 

1-5 Sept 

OPCAP Phase III Test on System 11 

6-7 Sept 

System debug System 11 

8-10 Sept 

Nimitz Crew Training 

11-12 Sept 

System Debug System 11 

13-15 Sept 

OPCAP Phase IV-A Tesr on System 11 

16-18 Sept 

OPCAP Phase IV-A Test on System 11 

19-20 Sept 

System Debug System 11 

21-23 Sept 

Contingency 

24-30 Sept 

Standard Measurement Technique (SMT) 

24-27 Sept 

Nimitz Crew Training 

28-30 Sept 

Contingency (End of Test Period A) 

- - .- -- 

TEST PERIOD B 

1 

1 

1 

1-6 Oct 

OPCAP Phase IV Test Demonstration | 


on System 11 


1 
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APPENDIX P 


NA7HACS HARDWARE SODDLARITY MATRIX 


- 1 

EQUIPMENT 

- ■ 1 

NAVMACS 

VI 

— -1 

NAVMACS 

V2 

r - 

NAVMACS 

V3 

r •" • 

NAVMACS 

V5 

AN/UGC-25 

PAGE PRINTER 

-.- .---- - 

4 

- 

- 


AN/UGC-20 

CONTROL TTY 

1 

1 



AN/OYK-20 

MINICOMPUTER 

----- - . - -- - - - 

r 

1 

1 

2 

3 

ON-143 

INTERFACE GROUP 

.... . .. ] 

1 

. 

1 

1 

1/2 

RD-397 PAPER TAPE 
READER PUNCH 

1 

1 

1 

2 

. 

C V-30 22 

LEVEL CONVERTER 

1 

1 

2 

2/3 

AN/USH-26 MAGNETIC 
TAPE UNIT 


1 

2 

2 

_ . .. 

TT-624 MEDIUM 

SPEED PRINTER 

- 

2 

2 

13/21 

AN/USQ-69 

KEYBOARD/DISPLAY 

- 

0/1/2 

2/3 

9/1 8 

1 - .. 

RD-433 

DISK FILE 

- 

- 

- 

- 

2 

KEYBOARD/PR INTER 

- 

J 

- 

0/16 
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APPE NDIX G 


A. SYSTSa SELECTION 

1. Basic Criterion 

rhs most important decision that the Communication 
Planners had to make was concerning the selection of the 
type of system which they were going to develop for instal¬ 
lation onboard the Niraitz. The system had to satisfy the 
major communications objectives of reducing human interven¬ 
tion, increasing processing speed, as well as being able to 
handle the extremely large volumes of message traffic nor¬ 
mally associated with air crafr carriers and their embarked 
Flag Officers' staffs. Importanr decisions had to be made 
concerning the number of manual activities to be automated, 
what functions should be placed online, and what processing 
speeds should be obtained. 

2. Alternative Dasion Approaches 

a. Semi-Automatic 

The KPDS developed for the USS Oklahoma Ciry 
(CG-5) is an example of a system which satisfied the stated 
objectives while using minimal hardware and software 
resources. The automated features of this system did not 
include remote terminal message and report retrieval ser¬ 
vices. Nor did it allow for remote terminal message 
transmission. 

b. Fully Automated 

The MPDS developed for the USS Nimitz offered 
maximum automation, high processing speeds, and very high 
message processing rates. The hardware and software were 
characterized by high interdependencies and sophistication. 

c. Hybrid Approach 

Many combinations of semi-automated and fully 
automated features were available for the planners to con¬ 
sider, Any system which performed the 

basic automated functions of the {CG-5) system would fall 
into this category. 
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built from exisr- 


3. Adva ntaqes 

a. Semi-Automated System 

The semi-automated system was 

ing hardware. It took minimal time to become fully 
operational. The cost to develop the CG-5 system was rela¬ 
tively low. 

b. Fully Automated System 

The CVN-68 system offered many online services 
to the users such as remote terminal message services [Ref. 
60]. These services have increased user productivity and 
communications accuracy. 

4. Oisa dvantaaes 

a. Semi-Automated 

This system requires a lot of manual interven¬ 
tion in the message handling process. The users have to 
walk their outgoing massages traffic to Radio Central. Mes¬ 
sage retrievals take a relatively long time to process. 

b. Fully Automated 

The primary disadvantages are high development 
cost and maintenance difficulties due to the high sophisti¬ 
cation of the hardware and software. 

5. Planners* Choice 

The planners had to make a performance/cost trade¬ 
off in selecting the communications system for HPDS. The 
decision to develop a highly automated system reflects the 
planners' emphasis on maximum performance. 

B. HARDWARE AND SOFTWARE SELECTION 

Another important area which was of concern to the plan¬ 
ners was hardware and software selection. Plans had to be 
made outlining policy on the use of existing hardware and 
software. Decisions had to be made concerning what specifi¬ 
cations would be used for items that had to be developed. 
The decisions made by the planners can be found in the 
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Military Specification and the Functional Description. The 
results of these decisions can be observed onboard the USS 
Nimitz and USS Eisenhower. 

1. Utilize Existing Units 

The planners decided to use existing equipment and 
design where they were available, for MPDS [Raf. 61]. The 
pieces of equipment which were to be used were listed in the 
Military Specifications, 

2. Develop New Units 

Another approach would have been to develop an 
entirely new suite of hardware and software. 

3. A dy an targes 

a. Utilize Existing Units 

Several savings can be obtained by using exist¬ 
ing units. The project can save a lot of time and money by 
not having to develop a new unit. The amount of risk 
involved in the development is also much lower when one has 
a known reliable unit in stock. 

b. Develop New Units 

The major advantage to developing new units is 
increase in performance. 

4 . Pisa dvan tapes 

a. Utilizing Existing Units 

The existing units may be functioning below the 
standards of the new equipment. Opportunities for improved 
performance may be lost because outdated units are not 
replaced by more efficient/effective units. 

b. Develop New Units 

New developments ofren run a high degree of risk 
which could result in a late delivery. New units often run 
up the cost of the project. 

5. Major Decisions 

Again the planners were required to make judgemental 
decisions about performance/cost trade-offs. Since new 
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units usually increased both performance and c 
existing units tended to reduce project cost, th 
had to select the appropriate trade-offs. 

The planners' decision to use existing 
MPDS proved to be a wise one since the new units e 
a lot of logistic problems [Ref. 62]. 


osr, and 
e planners 

units for 
X perienced 
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